Databases will Visualize Queries too

Visual Query Languages study ways to help users compose queries with visual metaphors. Information Visualization studies automatic visualization techniques to help users understand and analyze data. Query Management focuses on ways to help users manage and re-use existing queries. We observe that there is a related research question across those three topics which has not received much attention, namely that of Query Visualization: How to visually represent a query to help users quickly understand its intent? Here we argue that the involved challenges are still markedly different from those of the other three, that a solution can considerably improve the usability of DBMSs, and that the topic is thus worthy of attention. We envision, that in a few years, there will be free, modular, and lightweight tools available that allow users to visualize and interpret their queries. 1. QUERY INTERPRETATION IS HARD Query Interpretation is the problem of reading and understanding an existing query. It is often as hard as Query Composition, i.e. creating a new query [22]. Just like understanding program code, query interpretation requires guessing the line of thought of the query composer, making connections between attributes of tables, while keeping in mind the schema and aliases of tables. Hence, query interpretation requires significant comprehension of SQL and is even used for testing purposes [24]. Recently, several projects have focused on building Query Management Systems that help users issue queries by leveraging an existing log of queries. Known systems to date include CQMS [17, 18], SQL QuerIE [3, 1], DBease [20], and SQLshare [10]. All of those are motivated by making SQL composition easier and thus databases more usable [16], especially for non-sophisticated database users. An essential ingredient for such systems is a query browse †New contact info: [email protected] ∗Title strongly inspired by Ioannidis and Simitsis [14]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Articles from this volume were invited to present their results at The 37th International Conference on Very Large Data Bases, August 29th September 3rd 2011, Seattle, Washington. Proceedings of the VLDB Endowment, Vol. 4, No. 12 Copyright 2011 VLDB Endowment 2150-8097/11/08... $ 10.00. Query Composi-on Query Interpreta-on SELECT A FROM R WHERE B not in (SELECT D FROM S) Figure 1: Interpreting an existing query is often as hard as composing a new query (red = hard). facility, i.e. an interaction mode that allows the user to quickly understand and choose between several queries proposed by the system. Here, the optimal computer human interaction is similar to that for text snippets for search engines [23]: the computer searches through many and proposes a few (high recall), the human browses through a few and chooses one (high precision). As the queries are shown, their representation should be: (i) representative, so users can grasp the essence of the result from its snippet, (ii) distinguishable, so users can differentiate between queries with little effort, (iii) small, enough so users can quickly browse several query representations, while being (iv) selfcontained, so users can understand it without other help (four goals taken from [12]). In other words, the query representation should capture the query intent very concisely. Query representation. There are 4 principal options to help users interpret an existing query: (1) Visual manipulation of text : Clients to major DBMSs, such as SQL server management studio and pgAdmin for PostgreSQL, have been long highlighting different syntactic constructs or aligning query blocks and clauses. It is helpful, yet not sufficient to help users understand a query’s intention fast. (2) Translation into natural language: Ioannidis et al. [13, 14, 19] propose to explain queries in natural language. They convincingly argue that automatically creating effective freeflowing text from queries is difficult and the overall task quite different from previous work on creating natural language interfaces to DBMSs. (3) Illustration with example instances: Olston et al. [21] study the problem of generating example intermediate data for data flow programs that quickly illustrates the semantics of the operators to users. This approach could be applied to illustrating SQL queries with example input and output. (4) Visualizing the query : Query visualization creates a diagrammatic representation of an existing SQL query. It is thus the reverse of visual query languages which allow The term query intent captures the high-level goal of the query, independent of the actual choice of syntax.